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Protocol for Carrying Authentication for Network Access (PANA) Framework

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document defines the general Protocol for Carrying
   Authentication for Network Access (PANA) framework functional
   elements, high-level call flow, and deployment environments.
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1.  Introduction

   PANA (Protocol for carrying Authentication for Network Access) is a
   link-layer agnostic network access authentication protocol that runs
   between a client that wants to gain access to the network and a
   server on the network side.  PANA defines a new Extensible
   Authentication Protocol (EAP) [RFC3748] lower layer that uses IP
   between the protocol end points.

   The motivation to define such a protocol and the requirements are
   described in [RFC4058].  Protocol details are documented in
   [RFC5191].  Upon following a successful PANA authentication, per-
   data-packet security can be achieved by using physical security,
   link-layer ciphering, or IPsec [PANA-IPSEC].  The server
   implementation of PANA may or may not be colocated with the entity
   enforcing the per-packet access control function.  When the server
   for PANA and per-packet access control entities are separate, a
   protocol (e.g., [ANCP-PROTO]) may be used to carry information
   between the two nodes.

   PANA is intended to be used in any access network regardless of the
   underlying security.  For example, the network might be physically
   secured, or secured by means of cryptographic mechanisms after the
   successful client-network authentication.  While it is mandatory for
   a PANA deployment to implement behavior that ensures the integrity of
   PANA messages when the EAP method produces MSK, it is not mandatory
   to implement support for network security at the link-layer or
   network-layer.

   This document defines the general framework for describing how these
   various PANA and other network access authentication elements
   interact with each other, especially considering the two basic types
   of deployment environments (see Section 4).

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

2.  General PANA Framework

   PANA is designed to facilitate the authentication and authorization
   of clients in access networks.  PANA is an EAP [RFC3748] lower layer
   that carries EAP authentication methods encapsulated inside EAP
   between a client node and a server in the access network.  While PANA
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   enables the authentication process between the two entities, it is
   only a part of an overall AAA (Authentication, Authorization and
   Accounting) and access control framework.  A AAA and access control
   framework using PANA is comprised of four functional entities.

   Figure 1 illustrates these functional entities and the interfaces
   (protocols, APIs) among them.

                                                 RADIUS,
                                                 Diameter,
           +-----+       PANA        +-----+     LDAP, API, etc. +-----+
           | PaC |<----------------->| PAA |<------------------->| AS  |
           +-----+                   +-----+                     +-----+
              ^                         ^
              |                         |
              |         +-----+         |
      IKE,    +-------->| EP  |<--------+ ANCP, API, etc.
      4-way handshake,  +-----+
      etc.                 .
                           .
                           .
                           v
                      Data traffic

                       Figure 1: PANA Functional Model

   PANA Client (PaC):

      The PaC is the client implementation of PANA.  This entity resides
      on the node that is requesting network access.  PaCs can be end
      hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers
      that are connected to a network via a wired or wireless interface.
      A PaC is responsible for requesting network access and engaging in
      the authentication process using PANA.

   PANA Authentication Agent (PAA):

      The PAA is the server implementation of PANA.  A PAA is in charge
      of interfacing with the PaCs for authenticating and authorizing
      them for the network access service.

      The PAA consults an authentication server in order to verify the
      credentials and rights of a PaC.  If the authentication server
      resides on the same node as the PAA, an API is sufficient for this
      interaction.  When they are separated (a much more common case in
      public access networks), a protocol needs to run between the two.
      AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
      commonly used for this purpose.
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      The PAA is also responsible for updating the access control state
      (i.e., filters) depending on the creation and deletion of the
      authorization state.  The PAA communicates the updated state to
      the Enforcement Points (EPs) in the network.  If the PAA and EP
      are residing on the same node, an API is sufficient for this
      communication.  Otherwise, a protocol is required to carry the
      authorized client attributes from the PAA to the EP.

      The PAA resides on a node that is typically called a NAS (network
      access server) in the access network.  For example, on a BRAS
      (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
      (Packet Data Serving Node) [3GPP2] in 3GPP2 networks.  The PAA may
      be one or more IP hops away from the PaCs.

   Authentication Server (AS):

      The server implementation that is in charge of verifying the
      credentials of a PaC that is requesting the network access
      service.  The AS receives requests from the PAA on behalf of the
      PaCs, and responds with the result of verification together with
      the authorization parameters (e.g., allowed bandwidth, IP
      configuration, etc).  This is the server that terminates the EAP
      and the EAP methods.  The AS might be hosted on the same node as
      the PAA, on a dedicated node on the access network, or on a
      central server somewhere in the Internet.

   Enforcement Point (EP):

      The access control implementation that is in charge of allowing
      access (data traffic) of authorized clients while preventing
      access by others.  An EP learns the attributes of the authorized
      clients from the PAA.

      The EP uses non-cryptographic or cryptographic filters to
      selectively allow and discard data packets.  These filters may be
      applied at the link layer or the IP layer [PANA-IPSEC].  When
      cryptographic access control is used, a secure association
      protocol [RFC3748] needs to run between the PaC and EP.  After
      completion of the secure association protocol, link- or network-
      layer per-packet security (for example TKIP, IPsec ESP) is enabled
      for integrity protection, data origin authentication, replay
      protection, and optionally confidentiality protection.

      An EP is located between the access network (the topology within
      reach of any client) and the accessed network (the topology within
      reach of only authorized clients).  It must be located
      strategically in a local area network to minimize the access of
      unauthorized clients.  It is recommended but not mandated that the
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      EP be on the path between the PaC and the PAA for the
      aforementioned reason.  For example, the EP can be hosted on the
      switch that is directly connected to the clients in a wired
      network.  That way the EP can drop unauthorized packets before
      they reach any other client node or nodes beyond the local area
      network.

   Some of the entities may be colocated depending on the deployment
   scenario.  For example, the PAA and EP would be on the same node
   (BRAS) in DSL networks.  In that case, a simple API is sufficient
   between the PAA and EP.  In small enterprise deployments, the PAA and
   AS may be hosted on the same node (access router) that eliminates the
   need for a protocol run between the two.  The decision to colocate
   these entities or otherwise, and their precise location in the
   network topology, are deployment decisions that are out of the scope
   of this document.

3.  Call Flow

   Figure 2 illustrates the signaling flow for authorizing a client for
   network access.

                  PaC             EP               PAA              AS
                   |               |                |                |
      IP address ->|               |                |                |
      config.      |       PANA    |                |      AAA       |
                   |<------------------------------>|<-------------->|
                   |               |  Provisioning  |                |
      (Optional)   |               |<-------------->|                |
      IP address ->|               |                |                |
      reconfig.    |   Sec.Assoc.  |                |                |
                   |<------------->|                |                |
                   |               |                |                |
                   |  Data traffic |                |                |
                   |<----------------->             |                |
                   |               |                |                |

                       Figure 2: PANA Signaling Flow

   The EP on the access network allows general data traffic from any
   authorized PaC, whereas it allows only a limited type of traffic
   (e.g., PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.
   This ensures that the newly attached clients have the minimum access
   service to engage in PANA and get authorized for the unlimited
   service.

   The PaC dynamically or statically configures an IP address prior to
   running PANA.  After the successful PANA authentication, depending on



Jayaraman, et al.            Informational                      [Page 5]

RFC 5193                     PANA Framework                     May 2008


   the deployment scenario, the PaC may need to re-configure its IP
   address or configure additional IP address(es).  For example, a
   link-local IPv6 address may be used for PANA and the PaC may be
   allowed to configure additional global IPv6 address(es) upon
   successful authentication.  Another example: A PaC may be limited to
   using an IPv4 link-local address during PANA, and allowed to
   reconfigure its interface with a non-link-local IPv4 address after
   the authentication.  General-purpose applications cannot use the
   interface until PANA authentication succeeds and appropriate IP
   address configuration takes place.

   An initially unauthorized PaC starts PANA authentication by
   discovering the PAA, followed by the EAP exchange over PANA.  The PAA
   interacts with the AS during this process.  Upon receiving the
   authentication and authorization result from the AS, the PAA informs
   the PaC about the result of its network access request.

   If the PaC is authorized to gain access to the network, the PAA also
   sends the PaC-specific attributes (e.g., IP address, cryptographic
   keys, etc.) to the EP by using another protocol.  The EP uses this
   information to alter its filters to allow data traffic from and to
   the PaC to pass through.

   In case cryptographic access control needs to be enabled after PANA
   authentication, a secure association protocol runs between the PaC
   and the EP.  Dynamic parameters required for that protocol (e.g.,
   endpoint identity, shared secret) are derived from successful PANA
   authentication; these parameters are used to authenticate the PaC to
   the EP and vice-versa as part of creating the security association.
   For example, see [PANA-IPSEC] for how it is done for IKE [RFC2409]
   [RFC4306] based on using a key-generating EAP method for PANA between
   the PaC and PAA.  The secure association protocol exchange produces
   the required security associations between the PaC and the EP to
   enable cryptographic data traffic protection.  Per-packet
   cryptographic data traffic protection introduces additional per-
   packet overhead but the overhead exists only between the PaC and EP
   and will not affect communications beyond the EP.

   Finally, filters that are installed at the EP allow general purpose
   data traffic to flow between the PaC and the intranet/Internet.

4.  Environments

   PANA can be used on any network environment whether there is a
   lower-layer secure channel between the PaC and the EP prior to PANA,
   or one has to be enabled upon successful PANA authentication.
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   With regard to network access authentication, two types of networks
   need to be considered:

   a. Networks where a secure channel is already available prior to
      running PANA

      This type of network is characterized by the existence of
      protection against spoofing and eavesdropping.  Nevertheless, user
      authentication and authorization is required for network
      connectivity.

      a.1. One example is a DSL network where lower-layer security is
           provided by a physical means.  Physical protection of the
           network wiring ensures that practically there is only one
           client that can send and receive IP packets on the link.

      a.2. Another example is a cdma2000 network where the lower-layer
           security is provided by means of cryptographic protection.
           By the time the client requests access to the network-layer
           services, it is already authenticated and authorized for
           accessing the radio channel, and link-layer ciphering is
           enabled.

      The presence of a secure channel before the PANA exchange
      eliminates the need for executing a secure association protocol
      after PANA.  The PANA session can be associated with the
      communication channel it was carried over.  Also, the choice of
      EAP authentication method depends on the presence of this security
      while PANA is running.

   b. Networks where a secure channel is created after running PANA

      These are the networks where there is no lower-layer protection
      prior to running PANA.  Successful PANA authentication enables the
      generation of cryptographic keys that are used with a secure
      association protocol to enable per-packet cryptographic
      protection.

      PANA authentication is run on an insecure channel that is
      vulnerable to eavesdropping and spoofing.  The choice of EAP
      method must be resilient to the possible attacks associated with
      such an environment.  Furthermore, the EAP method must be able to
      create cryptographic keys that will later be used by the secure
      association protocol.
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      Whether to use

      b.1. link-layer per-packet security or

      b.2. network-layer per-packet security

      is a deployment decision and outside the scope of this document.
      This decision also dictates the choice of the secure association
      protocol.  If link-layer protection is used, the protocol would be
      link-layer specific.  If IP-layer protection is used, the secure
      association protocol would be IKE and the per-packet security
      would be provided by IPsec AH/ESP regardless of the underlying
      link-layer technology.

5.  Security Considerations

   Security is discussed throughout this document.  For protocol-
   specific security considerations, refer to [RFC4016] and [RFC5191].
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